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SECTION  1  -  INTRODUCTION 


1.1  PURPOSE 

An  index  identifies  and  references  information  which  is  exchanged  between  multiple  users 
and  systems.  The  increased  automation  that  will  take  place  as  CALS  evolves  will  dictate  an 
increased  use  of  indexes  for  the  successful  exchange  of  information.  Therefore,  indexing  is¬ 
sues  must  be  addressed  as  an  integral  component  of  the  overall  CALS  infrastructure  develop¬ 
ment. 

This  paper  examines  the  ways  in  which  the  use  of  indexes  can  support  CALS  and  DoD  objec¬ 
tives.  Specifically,  the  purpose  of  this  paper  is  to: 

•  identify  major  issues  related  to  indexing, 

•  survey  current  proposals  to  address  these  issues,  and 

•  make  recommendations  for  DoD  directions. 

This  section  provides  a  brief  introduction  to  indexing  in  DoD,  as  a  basis  for  the  subsequent 
consideration  of  the  issues  related  to  indexing. 

1.2  INDEXES  IN  DOD 

DoD  and  Industry  are  concerned  with  the  effective  management  of  large  volumes  of  informa¬ 
tion  about  weapon  systems.  The  ability  to  identify,  find  and  update  information  within  the 
CALS  structure  will  be  partly  dependent  on  the  strength  of  the  supporting  indexes.  The  basic 
purpose  of  an  index  is  to  provide  a  capability  for  organizing  data  to  enable  effective  storage, 
retrieval  and  distribution  of  that  data. 

Indexes  are  necessary  to  provide  the  structure  for  the  creation,  management  and  use  of  the 
information  in  any  large  system.  Indexing  procedures,  in  combination  with  other  information 
management  techniques  like  data  dictionaries,  configuration  management  and  data  security- 
schemes,  provide  the  control  capabilities  for  managing  data  in  the  CALS  environment. 

In  addition,  indexing  permits  access,  delivery,  and  presentation  of  information.  The  inherent 
structure  of  an  index  allows  the  relationships  between  data  in  diverse  environments  to  be  un¬ 
derstood.  For  example,  an  index  can  establish  a  relationship  between  assemblies  and  subas¬ 
semblies  of  a  weapon  system.  Indexes  also  enable  the  linking  of  appropriate  data  such  as  a 
part  drawing,  the  part  itself,  the  part  manufacturing  processes,  and  the  maintenance  activities 
needed  to  keep  the  part  operational.  Formalizing  these  relationships,  which  is  achieved  by 
the  indexing  system,  is  critical  to  the  management  of  the  Weapon  Systems  Life  Cycle  (WSLC). 

1 J  VALUE  OF  INDEXES 

The  evolution  and  use  of  indexing  systems  within  DoD  and  Industry  has  paralleled  the  evolu¬ 
tion  and  use  of  technology.  As  weapon  system?  became  more  complex  and  the  application  of 
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information  technology  became  necessary,  more  comprehensive  indexing  schemes  were  de¬ 
signed  and  employed  to  manage  inventories  (national  stock  number),  manufacturing  pro¬ 
cesses  (work  center  operation  codes  for  computer  numerical  control  machining  centers),  and 
technical  data  (engineering  drawing  numbers). 

Examples  of  the  potential  benefits  derived  from  specific  indexing  applications  are  summa¬ 
rized  below. 

•  An  index  can  increase  productivity  by  enabling  the  faster  retrieval  of  relevant 
information. 

For  example,  a  warehouse  design  can  be  based  on  an  indexing  system  which 
allows  for  the  storage  and  retrieval  of  information  by  frequency  of  use  of  the 
component  parts. 

•  An  index  can  improve  the  decision-making  process  by  providing  the  required 
information  in  a  useful  order. 

For  example,  a  decision  support  system  relies  on  the  orderly  classification  and 
indexing  of  the  information  needed  to  make  a  decision.  This  can  include  his¬ 
torical,  current  and  projected  data  for  consumption,  prices,  leadtimes  to  deliv¬ 
ery,  and  alternative  sources  to  improve  the  quality  and  speed  of  reprocurement 
decisions. 

•  An  index  can  support  effective  execution  of  plans  by  providing  a  common  refer¬ 
ence  to  information  that  everyone  uses  in  communications,  information  trans¬ 
fer  and  the  performance  of  their  tasks. 

For  example,  manufacturing  planning  and  scheduling  systems,  parts  ordering 
systems  and  automated  manufacturing  systems  can  all  refer  to  the  same  or  re¬ 
lated  information  through  the  same  indexes. 


SECTION  2  -  CALS  &  INDEXING  REQUIREMENTS 


An  important  thrust  of  CALS  is  the  emphasis  on  automation  for  information  transfer  and 
exchange.  This  information  exchange  is  complicated  by  the  large  volume  of  data  associated 
with  the  acquisition  of  weapon  systems,  and  rapid  identification  and  interpretation  of  ex¬ 
changed  information  is  essential.  As  automation  becomes  more  advanced,  the  demands  upon 
indexes  to  support  this  digital  information  transfer  becomes  more  pronounced. 

In  order  to  effectively  achieve  the  CALS  automation  objectives  and  more  particularly  the  in¬ 
dexing  capabilities  required  to  support  those  objectives,  indexing  issues  and  requirements 
should  be  approached  from  business  and  technology  perspectives. 

2.1  BUSINESS  RELATED  INDEXING  REQUIREMENTS 

Business  related  requirements  address  the  prudent  management  of  the  existing  technical  in¬ 
formation  that  supports  the  weapon  systems  life  cycle.  These  include: 

•  preserving  existing  information, 

•  exchanging  information  between  Services  and  Industry,  and 

•  integrating  information  across  Services. 

2.1.1  Preserving  Existing  Information 

Most  of  the  existing  weapon  systems  now  in  use  will  still  be  operational  in  the  year  2000  and 
beyond.  These  weapon  systems  are  supported  by  a  large  base  of  technical  information,  which 
is  essential  to  keeping  the  systems  operational.  These  existing  weapon  systems  will  be  modi¬ 
fied  and  their  supporting  information  will  be  updated  to  reflect  the  changes.  Preserving  the 
investment  in  the  unchanged  portions  of  the  weapon  system  and  its  technical  information  is 
essential. 

Indexes  provide  the  means  to  preserve  this  existing  information  base.  They  are  an  informa¬ 
tion  tool  that  assists  in  the  management  and  use  of  the  weapon  system’s  technical  information 
and  are  themselves  a  special  kind  of  information  because  they  make  the  rest  of  the  technical 
information  accessible.  Without  access  to  the  information,  the  support  of  the  weapon  system 
is  at  risk. 

2.1.2  Exchanging  Information  between  Services  and  Industry 

The  creation  and  modification  of  weapon  systems  involves  a  continuing  dialogue  between  the 
Services  and  Industry  until  the  final  equipment  and  technical  information  are  delivered.  Dia¬ 
logue,  in  the  form  of  reviews,  provides  Industry  with  feedback  and  historical  information  on 
weapon  system  performance.  Industry  provides  the  Services  with  the  information  required 
for  the  review  cycles  in  the  WSLC.  Before  a  weapon  system  is  delivered,  technical  informa¬ 
tion  containing  trade-off  choices  is  presented  by  Industry  so  that  the  Service  can  make  inputs 
into  the  design  and  refinements  can  be  made.  At  the  end  of  the  WSLC,  Industry  provides  the 
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Services  with  the  information  that  has  been  generated  by  the  process  which  in  turn  is  stored 
for  future  use  and  modifications.  As  CALS  evolves,  the  ability  to  provide  a  continuous  infor¬ 
mation  exchange  between  the  Services  and  Industry  will  become  necessary  and  will  rely  heavi¬ 
ly  on  indexes. 

The  precise  identification  of  the  exchanged  information  is  assisted  by  the  use  of  information 
indexes.  Indexes  are,  therefore,  instrumental  in  the  exchange  of  technical  information  be¬ 
tween  services  and  Industry  and  thereby  in  the  creation  and  modification  of  the  weapon  sys¬ 
tems. 

2.13  Integrating  Information  across  Services 

Integrated  information  accross  services  supports  interoperability.  This  interoperability  en¬ 
ables  services  to  exchange  information  about  commonly  used  systems  and  parts  (used  in  one 
or  more  services).  This  will  help  prevent  duplicate  data  purchase,  maintenance  and  indexing, 
while  also  supporting  duplicate  data  processing  activities. 

2.2  TECHNOLOGY  RELATED  INDEXING  REQUIREMENTS 

Indexing  needs  to  support  both  the  evolution  of  CALS  from  a  paper  intensive  environment  to 
an  integrated  information  environment  and  the  creation,  management  and  use  of  informa¬ 
tion  throughout  the  WSLC.  The  role  of  indexing  technology  in  the  WSLC  is  based  on  the 
changing  functional  requirements  as  the  data  evolves  from  its  creation  to  use.  These  func¬ 
tional  requirements  define  the  primary  characteristics  needed  in  an  indexing  approach  to  ef¬ 
fectively  support  the  WSLC. 

The  evolution  of  CALS  requires  the  development  of  technology  strategies  that  will  support 
increasingly  complex  data  interchange,  and  higher  levels  of  performance  resulting  from  the 
need  to  retrieve  information  from  a  distributed  database  environment.  These  technology  re¬ 
lated  requirements  must  be  supported  by  approaches  to  indexing  that  compliment,  support 
and  adapt  to  escalating  requirements. 

2.2.1  Indexes  and  CALS  Evolution 

FIGURE  1  depicts  four  steps  in  the  evolution  of  the  CALS  environment  from  paper  based 
processes  to  an  integrated  information  infrastructure  and  shows  the  indexing  support  re¬ 
quired  for  accessing  information  at  each  step.  The  paper  environment  calls  for  simple  se¬ 
quential  indexing  schemes  to  support  manual  searching.  The  digital  exchange  environment 
needs  to  be  supported  with  automated  indexing  schemes  for  data  stored  on  electronic  media. 
The  move  to  shared  databases  will  require  an  index  with  a  more  complex  search  and  retrieval 
capability  based  on  a  distributed  database  environment.  This  creates  an  additional  require¬ 
ment  to  translate  and  interpret  data  stored  in  a  variety  of  indexing  schemes  that  have  been 
adapted  for  the  specific  use  of  various  functional  areas.  The  progression  to  a  completely  inte¬ 
grated  information  structure,  characterized  by  the  absence  of  manual  intervention  in  the  data 
exchange,  will  require  logical  indexing  schemes  which  support  high  performance  data  access. 
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FIGURE  1.  INDEXES  &  CALS  EVOLUTION  STEPS 
■*> 

2.2.2  Indexes  and  Weapon  System  Data  Management  Requirements 

The  weapon  system  data  management  life  cycle  reflects  the  WSLC  and  the  technical  informa¬ 
tion  activities  that  support  it.  Data  management  across  the  WSLC  involves  the  creation,  in¬ 
terface,  storage,  distribution  and  use  of  data.  To  support  data  management  across  the  WSLC, 
the  requirements  for  indexing  technology  include  the  identification,  reference,  linkage,  seg¬ 
regation  and  location  of  data. 

The  relationship  between  the  major  data  management  functions  and  the  technology  require¬ 
ments  are  depicted  in  FIGURE  2.  When  data  is  created,  the  primary  concern  is  to  uniquely 
identify  and  “tag”  the  data.  As  the  data  is  transferred  to  repositories  the  major  technical  re¬ 
quirement  is  correct  reference  -  asking,  “did  you  get  what  you  asked  for?”  In  storing  data,  the 
major  requirements  are  linkage  -  relating  and  integrating  the  new  information  with  the  exist¬ 
ing  information  and  segregation  -  providing  for  the  security  of  DoD  and  Industry  data.  Dis¬ 
tribution  requires  correct  data  reference  -  a  precise  interpretation  of  data  requested  versus 
data  sent.  The  primary  concern  in  attempting  to  use  the  data  in  application  is  location  -  iden¬ 
tifying  “where  is  the  information?” 
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The  indexing  requirements  shown  in  FIGURE  2  are  discussed  below. 

Identification 

Proper  identification  of  data  as  it  is  created  is  crucial  to  its  effective  management  and  use. 
Thus  a  basic  requirement  for  an  index  is  to  be  able  to  uniquely  tag  an  item  of  data.  An  index 
must  also  provide  a  structure  for  the  identification  approach.  This  identification  structure,  in 
turn,  must  be  consistent  with  the  requirements  for  logical  storage  and  retrieval  of  data.  The 
structure  for  identifying  data  must  be  extendible  to  accommodate  future  requirements  with¬ 
out  disrupting  existing  data  identification  structures.  Thus  the  identifying  characteristics  of 
the  index  should  assist  in  the  effective  employment  of  information  throughout  the  WSLC. 

The  use  of  an  index  to  identify  data  is  essential  to: 

•  eliminate  or  reduce  duplicate  acquisition  of  data,  and 

•  promote  rapid  availability  of  data  when  needed. 

Reference 

The  ability  to  reference  any  created  and  changed  technical  data  is  required  fo-  its  transfer  to 
and  from  storage.  Referencing  includes  the  precise  interpretation  of  data  requested  and  sent. 
Referencing  of  data  is  also  necessary  to  combine  identical  data  in  different  databases  and, 
therefore,  helps  provide  the  bridge  from  one  database  to  another. 

Referencing  facilitates  the  interface  between  different  systems  using  separate  indexes  but  the 
same  data.  Multiple  indexes  have  evolved  historically  for  the  same  bodies  of  information 
within  different  organizations  and  functions.  It  is  therefore  expedient  and  necessary  to  pre¬ 
serve  these  indexes  and  by  so  doing  we  protea  the  organizational  investments  in  the  use  and 
management  of  those  indexes. 
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The  reference  requirement  for  indexes  is  necessary  for: 

•  sending  data  to  and  retrieving  data  from  databases  with  related  data,  and 

•  correctly  interpreting  data  from  other  databases. 

Linkage 

In  the  context  of  indexing,  linkage  is  concerned  with: 

•  the  need  to  connect  related  sets  of  information  within  one  database;  for  exam¬ 
ple,  linking  the  graphics  image  of  a  part  to  its  related  technical  specification, 

•  modeling  related  information  and  providing  the  means  to  implement  the 
models, 

•  providing  the  structure  for  storage  of  data  in  repositories, 

•  providing  the  means  to  navigate  within  the  information  repositories, 

•  the  ability  to  support  configuration  management. 

Segregation 

The  need  to  move  towards  integrated  digital  information  is  complicated  by  the  potential  elim¬ 
ination  of  information  security  afforded  by  the  current  isolated  automated  information  sys¬ 
tems.  Information  security  is  accomplished  in  the  current  isolated  environments  by  physical 
segregation  of  data  and  control  over  user  access.  In  an  integrated  information  environment, 
which  needs  to  take  into  account  all  security  considerations,  an  ability  to  logically  segregate 
data  and  an  ability  to  isolate  users  to  access  particular  information  is  essential. 

Indexing  provides  the  means  to  segregate  information  and  users  in  order  to  implement  securi¬ 
ty  requirements.  Information  in  an  index  can  be  assigned  a  security  classification.  Indexes  are 
instrumental  in  classifying  users  and  organizations  so  that  they  can  be  assigned  access  privi¬ 
leges  to  different  compartments  of  information. 

The  use  of  indexes  to  support  security  requirements  will  provide  the  ability  to; 

•  implement  levels  of  security  for  data, 

•  regulate  user  access  on  an  as  needed  basis,  and 

•  protect  proprietary  and  special  security  data  in  digital  storage. 

Location 

The  ability  to  locate  technical  information  is  critical  to  its  use.  From  a  user’s  perspective  it  is 
all  that  counts. 

The  requirements  on  indexes  to  support  location  include  the  ability  to: 

•  establish  data’s  existence  -  finding  if  data  exists  and  where  it  exists, 

•  efficient  retrieval  -  employ  logical  constructs  to  increase  search  speed,  and 
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•  support  multiple  functional  perspectives  -  allow  different  functional  users  to 
readily  access  the  information  they  need  based  upon  their  differing  entry  points 
to  and  requirements  from  the  information. 

2.23  Technical  Requirements  Summary 

FIGURE  3  summarizes  the  CALS  technical  indexing  requirements.  The  indexing  proposal 
which  are  under  consideration  for  CALS  are  summarized  in  Section  3  of  this  report,  and  are 
measured  against  these  requirements  to  help  determine  to  what  extent  they  answer  the  CALS 
needs. 


REQUIREMENT 

DEFINITION 

IDENTIFICATION 

Builds  unique  ID 

Defines  a  structure 

Easily  accepts  change 

Unambiguous  identification  of  each  item  of  data 

Structure  is  built  on  familiar  and  comprehensible  concepts 

Easily  extend  or  update  index  for  new  requirements 

REFERENCE 

Supports  data  transfer 
Establishes  bridges  be¬ 
tween  databases 

Supports  multiple  indexes 

Promotes  transfer  of  data  to  and  from  repositories 

Establishes  relationship  between  data  in  different  databases 

Preserves  existing  indexes  to  protea  organizational  investments 

LINKAGE 

Connects  related  data 
Implements  data  models 

Supports  configuration 
management  (CM) 

Provides  links  between  data  items  in  the  same  information  repository 

Provides  the  struaure  for  data  storage  and  the  ability  to  navigate  the  data 
models 

Ability  to  identify  multiple  versions  and  provide  change  control 

SEGREGATION 

Assists  data  security 

Limits  user  access 

Implements  security  schemes  in  an  integrated,  automated  environment 

Defines  the  boundaries  for  user  access 

LOCATION 

Establishes  existence  of  data 
Enables  efficient  retrieval 
Supports  multiple 
perspectives 

Finding  if  and  where  data  exists 

Facilitate  rapid  information  retrieval 

Allow  different  funaional  users  to  approach  data  based  on  their  unique  needs 

I 


FIGURE  3.  CALS  TECHNICAL  INDEXING  REQUIREMENTS 


SECTION  3  -  CURRENT  INDEXING  PROPOSALS 


Four  proposals  are  summarized  in  this  section,  each  of  which  addresses  the  CALS  automation 
objectives.  The  proposals  are: 

•  Technical  Reference  Index  Metaset  -  TRIM 

•  Logistics  Data  Indexing  -  LDI 

•  Rosen  Schneck  Index  -  RS-Index 

•  Universal  Numbering  Structure  -  UNS 

Each  indexing  proposal  focuses  on  a  particular  area  of  concern.  The  first,  TRIM,  is  focused 
on  linking  indexes.  LDI  is  attuned  to  the  needs  of  logistics  support  functions  and  their  use  of 
indexes.  RS-Index  concentrates  on  creating  a  new  unique  index  composed  of  manufacturing 
and  hardware  information.  UNS  extends  an  existing  hardware  hierarchy  index  with  configu¬ 
ration  management  information  deemed  essential  to  weapon  system  management. 

3.1  TECHNICAL  REFERENCE  INDEX  METASET  -  TRIM 

The  primary  focus  of  TRIM  is  to  provide  a  means  to  identify,  transfer  and  access  digital  infor¬ 
mation  between  databases.  The  TRIM  methodology  proposes  that  once  a  database  is  identi¬ 
fied  as  a  candidate  for  the  transfer  of  information  from  one  database  to  another,  then  it  would 
be  included  in  the  TRIM  “metaset.”  The  metaset  would  include  standard  data  keys,  current 
values  of  those  keys,  a  dictionary  of  data  elements  indicating  linkages  to  standard  keys  and  a 
library  of  cross  references  to  other  data  elements  which  would  be  used  used  in  building  trans¬ 
lators.  TRIM  maintains  the  existing  database  and  does  not  establish  a  unique  identification 
for  each  information  element,  independently  of  that  which  has  been  provided  by  the  existing 
indexes. 

Without  TRIM,  databases  would  require  individual  customized  translators  from  each  source 
database  to  each  target  database.  The  TRIM  concept  provides  a  way  to  manage  individual 
translation  efforts  and  create  a  more  generalized  and  reusable  translation  capability.  The 
transfer  of  data  from  a  government  or  Industry  database  to  a  target  database  would  require 
two  translation  steps  if  TRIM  was  utilized  rather  than  customized  translation.  The  source 
database  information  would  be  translated  into  information  readable  by  the  second  translator 
using  the  standard  TRIM  metaset.  The  second  translator  then  converts  the  information  into  a 
form  useable  by  the  target  database.  FIGURE  4  represents  the  data  transfer  path  within  the 
TRIM  concept. 

TRIM  allows  for  retrofitting  existing  databases  to  a  new  standard  by  a  proposed  metaset 
standard  as  a  conversion  link  between  a  limited  set  of  databases.  This  dictates  the  need  to 
create  and  manage  a  very  large  data  set  (the  TRIM  metaset),  whose  constituent  users  may 
have  conflicting  requirements  that  impose  a  significant  management  burden  on  the  system. 

TRIM  addresses  one  practical  obstruction  to  data  transfer  -  the  lack  of  consistency  and  uni¬ 
formity  in  indexes.  TRIM  overcomes  the  obstruction  by  proposing  a  system  to  translate  in- 
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dexes  and  data  between  files,  systems  and  functions.  TRIM  accomplishes  this  only  for  data¬ 
bases  registered  in  the  TRIM  system. 


FIGURE  4.  TRIM 

3.2  LOGISTICS  DATA  INDEXING  -  LDI 


LDI  proposes  a  universal  structure  to  index  and  identify  all  logistics  data  and  to  support  its 
management  and  use  throughout  the  WSLC.  Without  LDI,  different  logistics  functions  use 
their  own  indexes  to  refer  to  the  same  piece  of  hardware  and  different  functions  have  difficulty 
exchanging  information  about  the  same  piece  of  equipment.  LDI  overcomes  these  difficul¬ 
ties  by  creating  a  hardware/function  combination  index. 

FIGURE  5  gives  an  example  of  how  LDI  works  by  combining  a  hardware  identifier  for  hy¬ 
draulic  activator  with  a  function  identifier  for  provisioning  to  create  an  LDI  record  identifier 
for  provisioning  of  hydraulic  activators.  The  information  related  to  the  record  identifier  in¬ 
cludes  the  detailed  logistics  information. 

Using  the  same  hardware  ED  (e.g.  platform,  assembly,  subassembly  or  part),  it  is  possible  to 
find  the  infc -'nation  from  all  the  functions  for  a  particular  part.  When  assessing  or  making 
changes  to  a  part,  if  the  weapon  system  uses  LDI,  it  is  possible  to  find  all  the  logistics  interac¬ 
tions  associated  with  that  part. 

LDI  creates  a  new  logistics  oriented  composite  ID.  UDI  will  require  that  all  logistics  functions 
standardize  upon  a  common  means  of  identifying  hardware  for  a  weapon  system  and  a  com¬ 
mon  way  of  identifying  functions.  This  could  be  problematic.  In  addition,  the  LDI  concept 
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can  be  extended  to  define  standardized  manufacturing  and  engineering  functions.  This 
functional  standardization  can  then  become  the  basis  for  an  index  to  support  an  integrated 
database. 


FIGURE  5.  LDI  INDEX  AND  RECORD  CONCEPT 

LDI  presumes  a  commonality  of  functions  related  to  the  maintenance  of  each  piece  of  hard¬ 
ware.  While  there  is  a  similarity  between  functions  across  systems,  the  differences  can  be  so 
significant  that  they  could  result  in  system  unique  indexes.  The  hardware  function  index  struc¬ 
ture  may  not  result  in  unique  identification  of  data  which  could  lead  to  redundant  data  stor¬ 
age. 

The  LDI  strategy  for  storage  is  based  on  four  files  that  structure  functionally  related  informa¬ 
tion  rather  than  product  data  relationships.  The  LDI  product  data  model  merges  what  has 
been  traditionally  viewed  as  a  product  dta  model  with  a  functional  model.  Problems  of  man¬ 
aging  configuration  of  system  and  subsystems  are  also  not  directly  addressed. 


The  combination  ot  hardware  and  functional  capabilities  within  LDI  make  it  difficult  to  iso¬ 
late  access  to  information  and  provide  boundaries  for  user  access.  However,  LDI  provides 
efficient  functional  retrieval  and  does  allow  functional  users  to  approach  the  data  based  on 
their  unique  needs. 


Converting  a  weapon  system’s  database  to  accept  this  index  would  require  a  major  data  re¬ 
structuring  effort.  LDI  is,  however,  conceptually  and  technically  feasible  for  new  weapon  sys¬ 
tems  if  consensus  on  the  index  structure  can  be  found. 

3  J  ROSEN  SCHNECK  INDEX  -  RS-INDEX 

RS-Index  scheme  proposes  that  an  index  with  multiple  components  be  created  to  support  the 
data  transfer  needed  to  enhance  weapon  system  data  automation  and  improve  DoD  and  In- 
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dustry  productivity.  As  depicted  in  FIGURE  6,  the  index  would  span  industrial  production 
and  DoD  operations.  The  proposal  defines  the  following  requirements  for  an  indexing 
scheme:  identification  which  requires  uniqueness;  classification  which  requires  exclusivity; 
and  structural  contents  which  requires  nodal  identification.  Additionally,  the  proposal  identi¬ 
fies  the  need  to  include  time  and  space  elements  and  the  need  to  be  all  inclusive,  efficient  and 
flexible.  The  scheme  is,  according  to  the  proposal,  designed  to  be  fully  compatible  with 
IGES/PDES.  The  proposal  delves  deeply  into  the  conceptual  problems  related  to  translating 
what  it  refers  to  as  human  knowledge  or  human  information  processing  into  machine  knowl¬ 
edge  or  machine  information  processing  and  stresses  the  importance  of  establishing  stan¬ 
dards  for  databases. 


The  RS-Index  is  based  on  an  iterating  logical  inference  scheme  which  allows  for  the  develop¬ 
ment  of  a  Universal  Numbering  Scheme.  The  Universal  Numbering  Scheme  described  in  the 
RS-Index  proposal  would  consist  of  an  identification  code,  known  as  a  part  index,  designed  to 
be  hardware  or  software  specific  with  four  blocks  identified  as: 


•  Prefix  -  which  contains  the  complete  assembly  structure  of  the  unit 

•  Time  -  which  identifies  an  event  in  time 

•  Space  -  which  identifies  the  place  of  an  action  or  event 

•  Postfix  -  which  contains  the  complete  production  structure  of  the  unit 
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The  proposal  suggests  that  a  Universal  Numbering  Scheme  in  and  of  itself  is  not  a  solution,  it 
is  only  the  enabling  technology  that  permits  the  diversity  of  databases  in  computer  systems  to 
be  organized  and  integrated.  The  proposal  addresses  the  way  in  which  Industry  and  govern¬ 
ment  interrelate  in  producing  and  using  information.  The  interaction  between  these  two  ar¬ 
eas  dictates  a  need  for  developing  standards  for  data  and  databases. 

3.4  UNIVERSAL  NUMBERING  STRUCTURE  -  UNS 

UNS  or  Universal  Numbering  Structure  is  a  proposal  to  improve  weapon  system  support 
through  better  configuration  management  (CM).  UNS  proposes  an  extendible, 
multi-element  index  whose  components  are  illustrated  in  FIGURE  7.  UNS  is  composed  of 
elements  that  are  in  common  use  in  the  Air  Force  and  builds  on  the  knowledge,  training  and 
experience  of  AF  personnel  with  its  index  components.  In  addition,  UNS  provides  configura¬ 
tion  status  accounting  to  information  associated  with  a  weapon  system  and  a  pan. 


7  ELEMENTS 


/\  /\  /\  /\  /\  /\/\ 


COMPONENT 

LOCATOR 


FIGURE  7.  UNIVERSAL  NUMBERING  STRUCTURE -UNS 

The  first  four  elements  together  are  in  current  use.  The  first  two  elements  identify  the  system, 
subsystem,  and  sub-subsystem.  The  third  element  encodes  the  function  that  the  component 
performs.  The  fourth  element  locates  the  component  on  the  weapon  system.  The  last  three 
elements  have  been  added  to  identify  the  level  where  a  component  is  serviced  and  its  configu¬ 
ration  status.  This  index  identification  information  provides  manual  and  automated  systems 
with  an  enhanced  ability  to  perform  their  assigned  duties  with  greater  certainty  by  providing  a 
tool  that  helps  to  keep  information  current  with  weapon  systems  configurations. 


UNS  recognizes  that  multiple  numbering  (indexing )  schemes  are  used  by  different  disciplines 
to  identify  the  same  object  and  that  each  of  them  has  a  configuration  management  concern.  A 
UNS  was  proposed  in  order  to  better  integrate  shared  information  among  these  indexing 
schemes  and  reduce  or  eliminate  configuration  management  problems. 


UNS  uniquely  identifies  a  component  in  a  weapon  system  by  using  a  composite  of  existing 
indexes  and  a  strong  configuration  management  approach.  It  provides  for  the  transfer  of  in* 
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formation  between  databases  structured  by  weapon  system  functional  hierarchy  and  allows 
for  the  connections  of  a  component  to  its  higher  assemblies  and  to  its  system.  The  index  is 
designed  to  provide  information  on  the  physical  location  of  a  component  within  a  weapon 
system.  The  need  for  security  is  not  directly  addressed  but  the  structure  of  the  indexing 
scheme  does  not  preclude  the  inclusion  of  codes  to  address  security. 

UNS  is  best  applied  to  new  systems  or  systems  that  already  use  the  main  UNS  index  compo¬ 
nent.  UNS  cannot  be  applied  to  existing  databases  or  weapon  systems  that  do  not  use  UNS’ 
basic  component. 


SECTION  4  -  COMPARATIVE  ANALYSIS  OF  THE  INDEXING  PROPOSALS 


Each  indexing  proposal  highlights  some  aspect  of  the  indexing  requirements.  This  section 
compares  each  of  the  proposals  to  each  other  and  to  the  indexing  requirements.  The  propos¬ 
als  are  also  measured  against  overall  objective  criteria  to  better  understand  their  strengths 
and  distinctions.  The  comparisons  of  the  proposals  will  be  built  upon  to  draw  conclusions  and 
recommendations  in  the  final  section. 

4.1  COMPARISON  OF  INDEXING  REQUIREMENTS 

FIGURE  8  compares  the  four  indexing  proposals  in  terms  of  how  they  meet  indexing  require¬ 
ments  and  how  complete  they  are.  Some  of  the  findings  are  summarized  here: 

Identification 

•  UNS  provides  the  most  interpretive  index  structure  allowing  users  to  relate  the 
structure  to  specific  weapon  systems  and  subsystems.  It  identifies  the  hierarchy 
and  use  of  a  component  within  the  related  systems  and  subsystems.  RS-Index. 
through  its  four  index  component  approach,  also  provides  a  unique  ID. 

•  LDI  and  RS-Index  propose  creating  new  unique  indexes  that  will  not  preserve 
existing  investments  in  indexes  nor  do  they  enable  transfer  of  information  with 
indexes  other  than  their  own,  without  some  form  of  translation. 

•  None  of  the  index  formats  accept  change  readily.  The  UNS  proposal  appears 
to  accept  change  most  easily  because  it  allows  an  extension  to  existing  index 
structures. 


Reference 

•  TRIM  is  the  only  indexing  scheme  that  directly  addresses  the  requirement  for 
data  transfer  across  several  existing  databases  without  a  major  restructuring  of 
current  information. 

•  UNS  and  TRIM  both  could  facilitate  the  bridging  of  information  between  het¬ 
erogeneous  data  residing  in  separate  databases.  UNS  through  its  approach  of 
building  on  the  common  existing  index  structure  and  TRIM  through  building  a 
standard  cross  reference. 

Linkage 

•  The  mapping  and  linking  of  databases  in  each  indexing  scheme  is  limited  to 
those  databases  included  in  their  universe  and  those  databases  that  are  mapped 
to  their  supported  index(es). 

•  Each  indexing  proposal  establishes  the  database  links  and  the  navigation  paths 
within  information  repositories. 
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■ — ^Proposal 
Requ  iremeni 

TRIM 

LDI 

RS-lndex 

UNS 

IDENTIFICATION 

Builds  unique  ID 

TRIM  accepts  IDs  provided 
by  underlying  index 

Record  identification 
dependent  oo  combining 
indexes  but  ID  is  not 
unique 

Multiple  components 
make  a  composite  unique 

ID  possible 

Seven  element  composite 
unique  ID  based  on 
familiar  concept 

Defines  *  structure 

Structure  relies  oo  existing 
database  indexes 

Achieving  consensus  on 
indexing  structure  very 
difficult 

Structure  is  defined  but 
only  one  (of  three) 
indexing  components  uses 
familiar  cooceplt 

UNS  is  defined  by  tu 
simple  and  easily 
understandable  structure 

Easily  accepts  change 

Adding  databases  involves 
retrofitting  a  Urge  data  set 

Index  structure  makes 
extension  difficult 

Complexity  of  index  makes 
change  acceptance  difficult 

Extends  existing  familiar 
index  and  allows  for 
addirioa  of  new 
information 

REFERENCE 

Supports  data  transfer 

Data  transfer  supported  for 
a  limited  set  of  TRIM 
mapped  databases 

Only  supports  dau  transfer 
from  one  LDI  index  to 
another 

Data  transfer  supported 
for  RS  indexed  databases 
only 

UNS  designed  to  integrate 
shared  information 
through  supporting  data 
transfer 

Establishes  bridges 
between  databases 

T*o  step  transUtion 
provides  bridge  between 
TRIM  mapped  databases 

LDI  indexes  provide  for 
bridges  to  other  LDI 
indexes  in  the  same 
weapon  system 

Specifically  designed  to 
provide  budgets  for 
information  transfer 
between  military  and 
industrial  sectors 

By  building  a  common 
index  for  different 
daubases.  UNS  facilitates 
bridging  information 

Supports  multiple  indexes 

Supports  only  those  indexes 
included  in  TRIM  database 

Creates  new  single  source 
index  Does  not  support 
existing  indexes 

New  RS  indexes  are  not 
based  on  and  do  not 
support  existing  indexes. 

UNS  concept  recognizes 
multiple  indexing  schemes 

LINKAGE 

Connects  related  data 

Connects  data  in  TRIM 

DBs 

Different  logistic  functions 
can  ux  same  logistics  data 
using  LDI 

Design  to  link  hardware 
and  process  information 

UNS  makes  identification 
of  similar  information 
possible 

Implements  data  models 

Establishes  daubase  links 
and  supports  daubase 
navigation  for  TRIM 
registered  databases 

LDI  structured  data 
provide  navigation  paths 
for  DBs 

Provides  structure  for  data 
storage  and  ability  to 
navigate  in  three 
component  indexes 

UNS  provides  simple  but 
rigorous  structure  for  data 
storage  and  clear  paths  for 
navigating  data 

Supports  configuration 
management  (CM) 

TRIM  does  not 
independently  provide  CM 

CM  is  indirectly  addressed 
by  LDI 

CM  issues  not  addressed 
by  CM 

Good  CM  is  inlegral  to  the 
UNS  approach 

SEGREGATION 

Assists  data  security 

TRIM  mapped  indexes  can 
be  Ugged  with  security  level 

LDI  indexes  can  be 
assigned  security  levels 

RS  indexes  can  be  given 
security  levels 

UNS  indexes  can  have 
security  levels 

Limits  user  access 

TRIM  indexes  can  define 
boundaries  for  user  access 

LDI  can  set  user  access 
boundaries 

RS  defined  boundaries  can 
be  applied  to  users 

UNS  indexes  can  establish 
user  boundaries 

LOCATION 

Establishes  existence 
of  data 

Easy  access  to  TRIM 

ditA 

Product  support  in  LDI  for 
funding  daU 

RS  indexed  dau  can  be 
found 

UNS  data  can  be  readily 
found 

Enables  efficient  retrieval 

Use  of  familiar  indexes 
already  in  use  support  rapid 

Functional  data  retrieval  is 
efficient  but  unfamiliar 

LDI  indexes  may  hinder 
rapid  access 

Unfamiliar  RS  index  may 
reduce  speed  of  access 

Familiar  and  easily 
understandable  index  helps 
speed  access 

Supports  multiple 
perspectives 

TRJM  daubase  indexes 
reflect  multiple  functions 

LDI  only  supports  its  own 
view  of  data.  Does  not 
allow  users  to  approach 
data  for  own  unique  needs 

Multicomponent  index 
supports  access  from 
different  areas 

UNS  index  components 
support  several  views  of 

dau 

FIGURE  8.  KEY  CAPABILITIES  OF  INDEXING  PROPOSALS 


•  TRIM  and  LDI  do  not  contain  configuration  management  information  in  their 
index  They  rely  on  other  data  elements  to  contain  that  information.  RS-Index 
and  LDI  possess  configuration  information  embedded  in  their  index  structures. 
This  assists  users  in  data  identification  and  use. 

Segregation 

•  Although  requirements  for  information  segregation  is  not  directly  addressed 
by  any  of  the  proposals,  they  can  all  support  an  automated  data  security  system. 

•  User  access  to  information  can  be  supported  by  any  indexing  proposal  to  classi¬ 
fy  boundaries  and  grant  user  access  privileges  that  are  needed  in  an  overall  in¬ 
formation  security  system. 


Location 

•  TRIM  and  UNS  both  enable  the  use  of  familiar  indexes  that  are  in  current  use. 
This  simplifies  the  identification  and  location  of  the  required  data.  The  LDI 
and  RS-Indexes  are  based  on  unfamiliar  index  components. 

•  Although  each  index  enables  the  user  to  find  data  items,  its  usefulness  depends 
on  how  easily  and  quickly  this  can  be  done. 

•  TRIM  provides  the  means  to  access  information  from  different  functional  per¬ 
spectives,  whereas,  the  other  three  indexing  proposals  do  not  support  this  need. 

4.2  ANALYSIS  OF  PROPOSALS 

FIGURE  9  reviews  each  proposal  from  the  perspective  of  nine  other  criteria  deemed  to  re¬ 
flect  the  indexing  requirements.  The  following  analysis  highlights  how  each  of  the  indexing 
schemes  address  these  criteria. 

•  Major  Objective  -  The  major  objective  of  each  indexing  proposal  is  different 
ranging  from  linking  existing  databases  (TRIM),  assisting  logistics  functions 
(LDI),  creating  a  unique  universal  index  (RS-Index),  and  adding  configuration 
management  to  an  existing  index  (UNS) 

•  Major  Weakness  -  A  common  weakness  is  that  with  the  exception  of  UNS,  they 
do  not  absorb  change  or  extension  well.  All  proposals  are  limited  in  the  num¬ 
ber  of  indexes  they  can  link. 

•  Application  Domain  -  LDI,  RS-Index  and  UNS  can  apply  well  to  new  weapon 
systems.  UNS  and  TRIM  apply  well  to  existing  weapon  systems  which  use  their 
indexes. 

•  Feasibility  -  All  indexing  proposals  are  feasible  but  only  TRIM  and  UNS  seem 
practical  as  they  can  link  existing  databases  without  adding  any  major  new  bur¬ 
dens,  and  provide  a  basis  for  integrating  new  weapon  system  data. 
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N.  Indexing 

^^.Ptoposals 

Characteristic's^ 

TRIM 

LDI 

RS-Index 

UNS 

MAJOR  OBJECTIVE 

Link  anting  indexes  A 

daubaxex 

Assist  logistics  functions 

Create  a  unique 
universal  ID 

Extended  an  existing 
index  to  cover  CM 

MAJOR  WEAKNESS 

Limited  number  of 
indexes  -  not  extendible. 
Need  to  create  <  very 

Urge  dsu  set  to 
translate  indexes 

Only  applies  to  LDI 
indexed  databases.  LDI 
assumes  a  commonality 
of  functions  related  to 
hardware  maintenance 

Cumbersome  to  create 
and  apply 

Only  if  UNS  index  has 
been  created  for  new 
weapon  system.  Not 
use  till  for  existing 
weapon  system 

APPLICATION 

DOMAIN 

Any  databases  can  be 
included  in  TRIM 
metaset 

Logistics  function 
databases 

Only  applicable  to  new 
weapon  systems 

New  weapon  system 
indexes  are  pnme 
candidates  for  UNS 

FEASIBILITY 

Tbchnically  possible  but 
limited  to  data  sets  that 
have  been  included  in 
TRIM  metaset 

TfechnicaHy  pomibte  but 
requires  all  logistic 
functions  to  standardize 
identification  of 
hardware  and  function 

Technically  possible  but 
unfamiliar  index  may 
block  its  use 

A  technically  possible, 
practical  extension  to  an 
existing  index 

STANDARDS 

REQUIREMENTS 

TRIM  metaset  imposes 
standards  for  each 
included  index 

The  LDI  index  structure 
and  contenta  are  its 
standard 

Each  component  of  the 

RS  Index  contains  its 
own  standards 

Each  UNS  index 
component  a  governed 
by  sundards 

SECURITY 

Can  be  adapted  to 
address  security  needs 

Can  set  boundaries  for 
users  and  data  security 

RS  index  can  be  used 
for  data  St  user  security 

UNS  &  components 
can  support  security 

DATA  MANAGEMENT 

TRIM  creates  a  new 
data  set  with  additional 
data  management  needs 

DaU  managed  by 
current  functions  after 
new  indexes  are  set 

DaU  management 
remains  the  same  after 
new  RS  indexes  are 
introduced 

Current  functions 
continue  to  manage 
dau.  UNS  contains 
powerful  configuration 
status  accounting 
capability 

DATA  TRANSFER 

Data  transfer  supported 
for  a  limited  set  of 

TRIM  mapped 
daUbases 

Supports  transfer  from 
one  LDI  index  to 
another 

DaU  transfer  support 
for  RS  indexed 
daubases  only 

UNS  designed  to 
integrate  shared 
information  through 
supporting  dau  transfer 

CONFIGURATION 
MANAGEMENT  (CM) 

TRIM  does  not 
independently  provide 

CM 

CM  is  indirectly 
addressed  by  LDI 

CM  issues  not  addressed 
by  CM 

Good  CM  ts  integral  to 
the  UNS  approach 

FIGURE  9.  INDEXING  PROPOSALS  ANALYSIS  SUMMARY 

•  Standards  Requirements  -  There  are  no  currently  accepted  standards  for  in¬ 
dexing,  and  as  yet  no  clear  set  of  requirements  for  indexing  standards  have  been 
defined.  As  a  result,  each  index  proposal  attempts  to  define  its  own  standards. 

•  Security  -  No  indexing  proposal  contains  a  well  defined  security  component 
but  indexes  from  all  proposals  can  be  instrumental  in  assigning  security  classifi¬ 
cations  for  information  and  users. 
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•  Data  Management  -  TRIM  creates  a  new  layer  of  data  management  require¬ 
ments  which  will  require  cross-functional  coordination.  The  management  and 
use  of  the  other  indexing  schemes  can  be  done  at  the  local  user  level. 

•  Data  Transfer  -  Each  proposal  is  restricted  to  data  transfer  within  its  indexed 
bases.  Links  are  needed  to  transfer  data  to  new  databases. 

•  Configuration  Management  (CM)  -  RS*Index  &  UNS  include  configuration 
management  information  in  their  index  structure.  TRIM  and  LDI  rely  upon 
data  present  in  their  databases  to  track  CM. 


SECTION  5  -  CONCLUSIONS  AND  RECOMMENDATIONS 


This  report  has  examined  four  current  indexing  proposals  against  the  indexing  requirements 
formulated  in  this  analysis.  The  conclusions  are  summarized  in  this  section  and  are  followed 
by  recommendations  based  on  the  analysis. 

5.1  CONCLUSIONS 

In  FIGURE  10  each  proposal  is  mapped  against  the  data  management  functions  over  the 
WSLC.  By  proposing  to  build  a  cross-reference  that  allows  linking  of  diverse  databases,  the 
TRIM  approach  can  provide  the  near-term  capability  for  information  exchange.  The  UNS 
approach  provides  a  good  alternative  based  on  an  index  structure  built  around  the  weapon 
system  functional  hierarchy.  An  index  approach  based  on  a  combination  of  these  two  ideas 
where  the  TRIM  metaset  includes  the  weapon  system  breakdown  could  meet  a  broad  range  of 
indexing  requirements.  This  would  enable  the  acquisition  of  new  data  to  be  integrated  with 
existing  data  and  cross  referenced  through  the  TRIM  metaset. 


Indexing 

Proposals 

- Data  Management  Functions  over  the  WSLC - ^ 

Creation 

Interface 

Storage 

Distribution 

Use 

TRIM 

• 

o 

• 

• 

UNS 

• 

o 

• 

o 

o 

LDI 

o 

• 

RS-INDEX 

o 

o 

O  -  Meets  indexing  requirement  in  this  area 
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FIGURE  10.  INDEXING  PROPOSALS  &  DATA  MAN AGEMENT  FUNCTIONS 
The  findings  summarized  in  FIGURE  10  are  highlighted  in  a  brief  overview  of  each  proposal. 


TRIM 

•  The  TRIM  concept  specifically  addresses  a  near-term  CALS  priority  of  facili¬ 
tating  information  exchange  between  existing  databases. 

•  TRIM  provides  the  possibility  for  the  broadest  interface  for  existing  databases 
through  its  concept  of  building  a  “cross-reference’*  table  based  on  a  standard¬ 
ized  TRIM  metaset. 
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•  The  components  (data  elements,  keys  and  relationships)  of  the  metaset  can  be 
adapted  to  develop  new  conceptual  schemes  for  future  data  acquisitions  and 
storage. 

•  Through  its  ability  to  link  various  data  structures,  TRIM  can  support  a  wide 
range  of  data  distribution  requirements. 

•  The  metaset  concept  provides  strong  support  to  the  user  who,  for  example,  has 
access  to  information  which  is  structured  according  to  a  local  requirement 
(such  as  a  workplan),  and  who  wishes  to  access  information  from  another  data¬ 
base  structured  to  a  different  local  requirement  (such  as  a  part  number).  Using 
the  metaset  concept,  the  user  can  then  build  a  local  database  that  combines  the 
relevant  information  (e.g.,  workplan  and  part  number). 

•  The  benefits  of  having  a  metaset  would  have  to  be  measured  against  the  cost  of 
maintaining  and  processing  this  kind  of  data  structure  on  an  ongoing  basis. 

LDI 

•  Using  the  hardware  component  of  UD1  as  a  bridge  to  the  LDI  indexing  scheme 
could  be  very  effective  in  linking  a  product  database  to  a  functional  database 
such  as  maintenance  and  procurement. 

•  The  hardware/function  index  structure  may  not  result  in  a  unique  identification 
of  data  which  may  lead  to  redundant  data  storage  requirements. 

•  While  it  may  be  conceptually  possible  to  extend  LDI  to  include  other  functional 
areas  such  as  design  and  manufacturing,  in  practice  LDI  may  not  be  readily 
adaptable  to  support  databases  structured  along  product  data  models  such  as 
PDES. 

•  Restructuring  existing  databases  to  conform  to  LDI  would  require  extensive 
effort. 

RS-IndfiX 

•  RS-Index  scheme  has  a  manufacturing  orientation  and  attempts  to  provide  a 
structure  that  includes  the  relationship  between  technical  data  in  both  the  gov¬ 
ernment  and  Industry  domains. 

•  RS-Index  scheme  does  establish  a  unique  identifier  but  the  nature  of  the  com¬ 
ponent  modules  of  this  index  needs  more  definition.  The  rationale  for  includ¬ 
ing  the  time  and  space  module  in  the  index  is  not  clearly  established. 

•  The  RS-Index  notion  of  multiple  components  is  valuable,  but  the  proposal 
does  not  go  beyond  oudining  them  and  leaves  the  question  of  how  it  would 
work  in  specific  situations  unanswered. 

UNS 

•  The  UNS  scheme  extends  index  structure  which  is  already  in  use  within  the  Air 
Force. 
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•  The  UNS  index  is  designed  to  completely  identify  a  part  by  its  location  within 
the  weapon  system. 

•  Because  each  part  is  identified  within  a  specific  weapon  system,  it  is  difficult  to 
uniquely  identify  parts  in  common  use  across  weapon  systems. 

•  Because  UNS  builds  on  the  existing  Air  Force  index,  it  is  possible  to  connect 
existing  databases  structured  on  the  hierarchy  of  systems  and  subsystems. 

•  UNS  proposal  integrates  the  configuration  status  of  the  part  in  the  index  struc¬ 
ture. 

•  UNS  proposal  provides  the  means  to  extend  indexes. 

5.2  RECOMMENDATIONS 

This  paper  has  examined  essential  requirements  related  to  indexing  in  a  CALS  environment, 
and  reviewed  some  existing  proposals  for  addressing  these  requirements.  While  each  of  the 
proposals  might  be  applicable  to  a  specific  situation,  none  can  completely  meet  the  broad 
requirements  for  information  exchange  in  the  highly  automated  environment  envisioned  by 
CALS.  In  addition,  indexing  is  only  one  aspect  of  data  management  in  an  integrated  data 
structure.  The  following  near  term  and  longer  term  recommendations  provide  guidelines  for 
developing  an  indexing  capability  that  addresses  the  existing  and  emerging  needs  as  the 
CALS  environment  evolves 

NEAR  TERM  RECOMMENDATIONS 

•  Link  existing  systems: 

Building  a  cross  reference  of  specific  information  that  will  allow  users  access  to 
related  information  resident  in  diverse  databases.  Specific  steps  to  accomplish 
this  task  should  include: 

•  Identifying  CALS  significant  databases  that  contain  technical  data 
that  need  to  be  linked  to  support  the  transfer  of  information* 

•  Identifying  the  keys  currently  used  to  index  these  databases. 

•  Establishing  appropriate  relationships  between  keys  to  support  data 
access  requirements. 

•  Prototype  specific  proposals: 

Proposals  that  specifically  address  the  need  to  cross-reference  data,  (namely 
TRIM  and  UNS),  may  be  prototyped  in  the  current  environment  of  an  opera¬ 
tional  locator  system  like  MEDALS  (Military  Engineering  Data  Asset  Locator 
System)  to  demonstrate  the  utility  of  linking  different  databases.  Specific  tasks 
to  support  this  prototyping  include: 

•  Identifying  functional  areas  within  a  system  that  require  data  from 
multiple  sources. 
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•  Developing  a  prototype  cross  reference,  an  enhanced  index,  and  a 
schema  which  will  facilitate  data  exchange. 

•  Hosting  the  prototype  on  an  operating  environment  that  supports  a 
specific  activity  to  demonstrate  the  utility  of  linking  the  data  bases. 

LONGER  TERM  RECOMMENDATIONS 

•  Develop  Indexing  Concepts: 

Additional  effort  is  required  to  completely  define  and  validate  DoD  require¬ 
ments  for  an  indexing  scheme.  This  paper  provides  an  initial  framework  for 
considering  the  value  of  indexing  in  a  functional  context.  Specific  additional 
tasks  that  should  be  considered  include: 

•  Validating  the  indexing  requirements  identified  in  this  paper. 

•  Establishing  important  components  that  should  be  included  in  the 
index  to  support  a  variety  of  user  perspectives  on  data  access. 

•  Determining  the  nature  of  an  index  “kernel”  -  the  least  common  de¬ 
nominator  which  should  be  included  in  an  index.  This  “kernel”  be¬ 
comes  the  core  standard  from  which  the  rest  of  the  index  is  built. 

•  Defining  how  an  index  “kernel”  will  support  specific  functional  area 
requirements  for  customized  indexes  while  enabling  the  exchange  of 
information  with  other  CALS  compliant  data  bases.  This  “kernel’' 
becomes  the  core  standard  from  which  the  functional  areas  will  be 

•  able  to  build  their  own  customized  indexes. 

•  Define  Indexing  Standards: 

The  first  step  towards  developing  and  indexing  standard  is  to  define  which  ele¬ 
ments  of  an  index  must  be  included  in  a  standard.  An  indexing  standard  must 
be  developed  that  will  allow  new  indexes  to  meet  specific  functional  require¬ 
ments  within  a  well  defined  index  structure.  This  steps  to  achieve  this  would 
include: 

•  Developing  standard  specifications. 

•  Developing  tests  for  index  standards 

-  Conformance  testing 

-  User  testing 

•  Coordinating  with  Industry 

•  Integrate  Indexing  Strategy  with  the  CALS  Data  Management  Infrastructure: 
Indexing  strategy  must  be  considered  in  the  context  of  overall  data  manage¬ 
ment  infrastructure.  This  includes  other  data  management  concepts  such  as 
data  dictionaries,  configuration  management  and  data  security.  There  is  a 
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need  to  coordinate  standards  development  in  all  data  management  areas.  This 
would  include: 

•  Including  index  standards  in  defining  data  dictionary  standards 

•  Assessing  the  relevance  of  including  data  security  elements  in  index¬ 
ing  structures. 

.  Ensuring  index  support  for  configuration  management. 
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